home *** CD-ROM | disk | FTP | other *** search
/ The Utilities Experience / The Utilities Experience - Volume 1.iso / software / disk_tools / mrbackup / docs / mrtape.doc < prev    next >
Text File  |  1995-03-05  |  9KB  |  173 lines
  1.  
  2. MRTape: SCSI Tape Handler V1.30
  3. -------------------------------
  4.  
  5. Author: Mark R. Rinfret, MRsoftware
  6. Date:   03/05/95
  7.  
  8. This is a tape handler designed primarily for MRBackup
  9. Professional.  Portions of this handler were originally derived
  10. from code written by Markus Wandel and Bob Rethemeyer.  I am very
  11. grateful to them for their contributions to my understanding of
  12. SCSI tape operations.
  13.  
  14. The MRTape-Handler is made accessible to the system by placing a
  15. copy of its executable program in the L:  directory, then
  16. mounting it via an AmigaDOS mountlist entry (a sample appears
  17. later in this document).  The suggested device name is "MRTape:"
  18. but you are free to call it anything that conforms to AmigaDOS
  19. device naming conventions, since the name you choose for the
  20. mountlist entry is the name given to the device entry.
  21.  
  22. The contents of a magnetic tape can be thought of as a series of
  23. zero or more 'files', separated by 'file marks' (or tape marks,
  24. if you prefer).  Each time a program opens an MRTape-Handler
  25. device for write access, a file mark is written at the end of
  26. data when the device is eventually closed.  Multiple 'files' can
  27. be stacked on a given tape.  These 'files' can also span multiple
  28. physical tape cartridges.  In this case, the individual tape
  29. cartridges collectively appear as one very large tape cartridge.
  30. Each of the 'files' on an MRTape-Handler created tape is numbered
  31. consecutively from zero (0) through the number of files minus 1.
  32. Each MRBackup saveset constitutes one tape file, though it
  33. actually contains many AmigaDOS files and directories.
  34.  
  35. The MRTape-Handler's behavior when opening a tape can be altered
  36. significantly by appending certain letter codes or a number after
  37. the colon at the end of the device name.  The various forms that
  38. a tape name specification can take are as follows:
  39.  
  40. MRTape:
  41.     The tape is opened and rewound immediately.
  42.  
  43. MRTape:A
  44. MRTape:AN
  45.     If the tape is opened for input (read access), it is just rewound.
  46.  
  47.     If the tape is opened for output (write access), it is first
  48.     rewound, then positioned such that new data will be written after
  49.     all existing data on the tape. If 'A' is specified, the tape will
  50.     rewind when it is closed. If 'AN' is specified, the tape will not
  51.     rewind when it is closed. This mode is useful when you want to
  52.     append data to a tape which was previously written to and then
  53.     removed from the tape drive.
  54.  
  55. MRTape:N
  56.     The tape is opened and not rewound on opening or on closing.   
  57.     A file mark will be written upon closing.  This mode is useful
  58.     when writing multiple savesets to a single tape in one session
  59.     (the tape is not removed from the drive between sessions).
  60.     Almost all tape drives will rewind a tape cartridge when it
  61.     is inserted.  Thus, MRTape:N can be used for all savesets
  62.     stacked in a single session.
  63.  
  64. MRTape:<number>
  65. MRTape:<number>N
  66.     When the tape is opened for output, the <number> parameter
  67.     is ignored.
  68.  
  69.     When the tape is opened for input, the handler will attempt
  70.     to position the tape to the beginning of the logical file
  71.     specified by <number> (a value from 0 to number-of-files minus 1).
  72.     If 'N' follows the number, the tape will not be rewound when
  73.     it is closed. Otherwise, the tape is rewound.
  74.  
  75.  
  76.     
  77. MRTape-Handler has been written to conform to the base SCSI standard
  78. and should therefore be compatible with most tape drives which can be
  79. used on the Amiga.  There are bound to be exceptions to that general
  80. rule, however.  If you have difficulties, I'll do what I can to help.
  81. I can provide a debug version of MRTape-Handler with a corresponding
  82. monitor program which will report in excruciating detail on every
  83. operation that MRTape-Handler performs.  The information collected can
  84. be analyzed and used to make adjustments (or a custom handler, if
  85. necessary).  I've also received reports of strange behavior on some
  86. GVP SCSI interface cards in certain Amiga configurations.
  87.  
  88. The meaning of the word "handler" is significant in Amiga terms.
  89. MRTape-Handler responds to standard AmigaDOS I/O packets (plus a few
  90. custom packets which MRBackup will use if they are supported) and
  91. attempts to present the same basic behavior that you would expect to
  92. observe when accessing an AmigaDOS file.  Implementing tape support
  93. in this way (as opposed to embedding SCSI-direct calls within the
  94. MRBackup Professional program) provides a large degree of device
  95. independence for MRBackup Professional.  MRBackup Pro simply writes a
  96. stream of data (encoded in MRBackup's "FastDisk" format) to the Backup
  97. Path.
  98.  
  99. Because of this high-level design choice, you can easily
  100. substitute other handler-based tape drivers if you have a
  101. particular preference or you're experiencing a problem with
  102. MRTape-Handler.  Excellent alternatives include Bob Rethemeyer's
  103. BTNTape (Better Than Nothing Tape handler) and Matt Dillon's
  104. DTape.  There must be a few others by now.
  105.  
  106. MRBackup currently treats the backup set as one contiguous file.
  107. Individual files have special header blocks and the data blocks
  108. have control information which defines the end of each file.
  109. There is a special control block to mark the end of tape.  Thus,
  110. the filemark isn't typically ever "read" and isn't required,
  111. which is how the 3M drive (block-structured) is able to work.
  112.  
  113. The buffer size parameter in the Startup field of the mountlist
  114. entry must be chosen with care.  This is the size of 1 buffer (as
  115. opposed to 1 block, as is typically specified for filesystems).
  116. The handler allocates one buffer for synchronous I/O and two
  117. buffers when using asynchronous I/O.  For example, I reccommend 8
  118. (8192 bytes) for the 3M drive (this is required by the drive) and
  119. 64 (65536 bytes) for the Wangtek 5150 ES.  The Wangtek has a 64K
  120. cache buffer.  Setting MRTapeHandler to use 64K buffers causes
  121. 128K bytes to be allocated (a significant chunk!) but performance
  122. is quite good.  To obtain the best performance for other drives,
  123. you may need to experiment.  Use MRBackup Professional's
  124. "Throughput" measurement as a relative guide to the effects that
  125. changes in buffer sizes have on your backups.
  126.  
  127. Here is a sample mountlist entry for MRTape-Handler:
  128.  
  129. /*  This is a mountlist entry for the SCSI tape handler provided with   */
  130. /*  MRBackup. Pay particular attention to the StartUp message. Its      */
  131. /*  format is:                                                          */
  132. /*      "<buffer_size>/<device_name>/<unit>/<luno>/<flags>"             */
  133. /*                                                                      */
  134. /*  where                                                               */
  135. /*      <buffer_size> is the total amount of buffer memory, specified   */
  136. /*      in K (K = 1024);                                                */
  137. /*                                                                      */
  138. /*      <device_name> is the SCSI device driver name;                   */
  139. /*                                                                      */
  140. /*      <unit> is the SCSI unit number;                                 */
  141. /*                                                                      */
  142. /*      <luno> is the SCSI logical unit number (not currently used but  */
  143. /*      must be set to zero);                                           */
  144. /*                                                                      */
  145. /*      <flags> is a set of bits controlling certain tape drive options */
  146. /*      The bit values, which may be added together are:                */
  147. /*                                                                      */
  148. /*          1   asynchronous mode, 0 = synchronous mode                 */
  149. /*          2   use on-board buffer, 0 = don't use on-board buffer      */
  150. /*                                                                      */
  151. /*          Example: to enable async mode and the on-board buffer, the  */
  152. /*          <flags> value would be 3 (1 + 2).                           */
  153. /*                                                                      */
  154. /*          Other flag bits will be provided as new features are added. */
  155.  
  156. MRTAPE:    Handler = l:mrtape-handler
  157.            StartUp = "64/scsi.device/4/0/3"
  158.            Stacksize = 4000
  159.            Priority = 10
  160.            GlobVec = -1
  161. #
  162.  
  163.  
  164. To determine the version number of MRTapeHandler, view the
  165. handler with any binary file editor and look for a string that
  166. begins with the letters "$VER:".  You may also use the "version"
  167. command under WorkBench 2.0.
  168.  
  169. To unload an instance of the MRTape:  handler, just use the
  170. Dismount option of the Assign command.  Here's an example:
  171.  
  172.     Assign DISMOUNT MRTape:
  173.